• Appendix A — Visual Basic versus Other Languages
• by Greg Perry
• The Other Basics
• Mainframe COBOL and Visual Basic 4.0
• C and Visual Basic 4.0
• Pascal A Language Whose Potential Has Gone
• C++ The True Visual Basic 4.0 Opponent
• Summary

— Appendix A —

Visual Basic versus Other Languages

by Greg Perry

If you have programmed using other programming languages before, you might be wondering how Visual Basic 4.0 compares to those languages in speed, power, flexibility, and ease of use. This appendix surveys several popular languages in use today and discusses how Visual Basic 4.0 responds to the challenge of meeting or surpassing those languages' capabilities.

Instead of comparing Visual Basic 4.0 to other languages command by individual command, this appendix discusses the main attributes of the languages and shows you how Visual Basic 4.0 supports or does not support those language attributes. By studying the comparisons you will be able to understand Visual Basic 4.0's strengths and weaknesses against these other languages. Visual Basic 4.0 is not necessarily the best language for every job. Although your specific application's requirements will ultimately determine whether or not you should use Visual Basic 4.0 or something else, this appendix will help you make the language decision.

The Other Basics

The roots of Visual Basic 4.0 date back to the early 1960s when, at Dartmouth University, two college professors set out to develop a programming language and environment in which non-programming students could write programs using a language easier than COBOL or FORTRAN. The result was BASIC whose acronym name stands for Beginner's All-purpose Symbolic Instruction Code—an acronym that is more difficult to remember than most of the commands in the language!

Not only was BASIC easier to learn than the other languages of the time; it was easier to use. Instead of being a compiled language, the novice student programmers could write their programs and execute those programs within the same interactive environment. BASIC was the first widely-used interpreted language. Here are the steps programmers then needed to write and execute a compiled, non-interpreted language program:

1. Write the program.
   
   
2. Compile the program.
   
   
3. Link the program.
   
   
4. Run the program.
   
   

These four steps were more time-consuming in the days of old than today because many of today's compiled language environments help shelter the programmer from the second and third steps. When BASIC was developed, each of these four steps required tedious commands that were often not understood by those using them. Interpreted BASIC honed those steps down to these two:

1. Write the program.
   
   
2. Run the program.
   
   

The primary problem with the early BASIC language was its lack of structure. The BASIC language really is not that much easier to learn than other languages, but it's easier to use. The original BASIC language was rigid and did not support the free-form control structures available in most of today's languages including Visual Basic 4.0. Listing A.1 contains a BASIC program listing. Now that you've learned Visual Basic 4.0 you will notice these items about the program:

• Line numbers are required at the left of each statement.
  
  
• The remarks are rigid and do not easily help describe surrounding code.
  
  
• Variable names are virtually meaningless due to their limited length (some versions of BASIC allowed for variable names that contained only two letters)
  
  

Note

BASIC was written long before windowed environments were available.

Listing A.1. A BASIC program must follow unstructured and rigid coding rules.

10 REM A PROGRAM TO CALCULATE FACTORIALS

20 F = 1

30 PRINT "WHAT IS YOUR NUMBER";

40 INPUT N

50 REM STEP THROUGH THE NUMBERS FROM ONE

60 REM TO THE USER'S ENTERED VALUE

70 FOR I = N TO 1 STEP -1

80 F = F * I

90 NEXT I

100 PRINT

110 PRINT "THE FACTORIAL IS"; F

120 END

As you've seen throughout this book, the language format of Visual Basic 4.0 greatly surpasses this rigid style of BASIC. The two languages are so greatly different that a side-by-side comparison is unneeded at this stage. No vendor currently supports the old style of the BASIC language. The importance of discussing BASIC comes in learning the roots of Visual Basic 4.0 and in understanding why Microsoft designed Visual Basic 4.0 to work the way it does.

How important was BASIC to the design of Visual Basic 4.0? Some might think that BASIC is so far from Visual Basic 4.0's capability that there is no need to make the comparison. The truth is that the old interpreted BASIC played a major role in Visual Basic 4.0's current design. Not only are many of the same language commands supported in both languages, such as For-Next loops, assignment statements, and If-Else comparison statements, but Microsoft designed Visual Basic 4.0 to be an interpreted language. Although a Windows-based language must be event driven (see the next section for more discussion on event driven versus procedural languages), the BASICs that came before Visual Basic 4.0 had a direct impact on the make-up of Visual Basic 4.0.

In today's programming world, the idea of an interpreted language is often scoffed at until someone sees Visual Basic 4.0 in action. Interpreted languages are inherently slower than compiled languages. Applications are often time critical and must run as fast as possible. Knowing this, developers often forego Visual Basic 4.0 in favor of a much more difficult language such as Visual C++. (A later section in this appendix compares Visual Basic 4.0 to C++ languages.) These developers often forget the following points:

• Computers are getting faster every day, not slower. As the speed of computers increases, the speed differences between running compiled and running interpreted programs becomes less and less critical.
  
  
• The time it takes to develop programs is often much more costly to developers and end-users than speed difference costs of the completed running programs.
  
  
• Despite the fact that compiler developers are making compilers easier to use, interpreted languages require far fewer system resources, fewer programmer-controlled options, and a smaller learning curve than using a compiled language such as Visual C++.
  
  

Microsoft added BASICA and a version of GWBASIC (standing, respectively, for BASIC Advanced and Gee-Whiz BASIC) to the MS-DOS operating system starting with the very first IBM PC. The success of PCs and MS-DOS compatibles ensured that those versions of BASIC were available to the masses of computer users.

Over the years, Microsoft improved upon the original line-numbered uppercase BASIC language. In the early 1980s, Microsoft developed QuickBasic, a compiled version of BASIC that finally eliminated the line numbers and turned the BASIC language into a language that professional developers began to take seriously. QuickBasic survived four major versions and improvements. By adding more control statements such as While options, ElseIf, and Case statements, and by improving the language's readability by supporting separate sub-programs and external routines, the BASIC language continued to thrive whereas it may have withered away without the improvements.

Beginning with MS-DOS 5.0, Microsoft introduced QBasic, an interpreted version of QuickBasic that included a full-screen editor and added the structured control statements that were so popular in QuickBasic. It was not until Windows 95 appeared that Microsoft failed to add an interpretive BASIC-like programming language to a major operating system product.

QuickBasic: The Now-Forgotten Compiled BASIC

Why did Microsoft introduce the QuickBasic compiler, improve the language through four versions, and then revert back to interpreted languages such as QBasic and Visual Basic and eliminate all support for a compiled QuickBasic? Perhaps Microsoft thinks that the interpreted environment is simply too appealing for novice programmers. In spite of the increased responsibilities of compiler users, however, the QuickBasic environment made the task of compiling and running programs almost as easy as using interpreted languages.

Microsoft may have dropped QuickBasic because of the timing of Windows. As Windows gained more popularity during the 1980s there was less and less reason to support a compiled MS-DOS language, albeit a well-written language, such as QuickBasic. Microsoft left QBasic in their operating system for several years after QuickBasic faded into the background but did not improve upon QBasic significantly since its first release in MS-DOS 5.0.

Note

One of the biggest language failures in computer history was Visual Basic for DOS. In the early 1990s, Microsoft produced an MS-DOS version of Visual Basic that supported the same visual interface as Windows only doing so in the MS-DOS mode. Programmers who wanted a Windows-like full-screen interactive interface could have that interface in MS-DOS. Sadly for Microsoft (and for MS-DOS program developers), Visual Basic for DOS appeared just at the time that Windows took off strongly; the need for an MS-DOS programming environment died along with Visual Basic for DOS in just a few short months. The surprising thing is that Visual Basic for DOS was a true compiler and yet never achieved the success or use that any one of Microsoft's interpreted BASIC languages achieved.

Table A.1 presents an overview of some of the specific feature comparisons between Visual Basic 4.0 and many of the BASIC languages that appeared over the years.

Table A.1. Visual Basic 4.0 compared to the other BASICs.

Visual Basic 4.0

BASICs

Mainframe COBOL and Visual Basic 4.0

In the mainframe/PC combination environment found in many of today's corporations, many programming shops are faced with using both a mainframe language and then supplementing that language with a PC-based language for the smaller work areas. The most popular high-level mainframe language still in use today is COBOL.

There are several PC-based COBOL languages on the market. The problem with many PC COBOL compilers is their support for Windows. Although there are COBOL compilers that support Windows program development, COBOL was never designed to be used in a graphical user environment. Instead of using a COBOL compiler for your mainframe application and a PC-based COBOL compiler for your PC applications, you should probably stick with COBOL for the mainframe and use Visual Basic 4.0 for your PC applications, whether or not you ever need to interface those applications to the mainframe.

COBOL was originally designed to be a procedural language. Procedural languages work well in text-based data-processing environments because procedural languages respond to sequential events. When a Windows screen appears, with command buttons, option buttons, scroll bars, and dropdown listboxes, the program reacting to that user's screen must be event-driven to handle whatever action the user performs next. A language such as COBOL simply cannot handle the interactions a Windows program needs.

About the only advanced user-interface allowed in traditional COBOL is a menu selection. Suppose that you display a five-element menu for the user. The menu might offer the user the following choices:

1. Add a customer record
   
   
2. Remove a customer record
   
   
3. Change a customer record
   
   
4. Print a customer detail report
   
   
5. Terminate the program
   
   

The user might enter one of five values in response to this menu. Some might think that, in an archaic sense, a text menu offers a primitive form of an event-driven user interface because the user might enter any one of five values (ignoring error conditions for now which are special events in and of themselves in a proper event-driven environment). Nevertheless, such a menu is a procedural screen interface element because the code needed to handle the menu is standard decision-making code as shown here:

GO TO ADD-CUST-PARA,

      REMOVE-CUST-PARA,

      CHANGE-CUST-PARA,

      PRINT-REPORT-PARA,

      END-PGM-PARA

DEPENDING ON USER-RESPONSE.

In the Visual Basic 4.0 environment, an option button might control the action requested by the user. A pull-down menu might be available for a printed report. The user might display an existing customer record, and then, decide to change one or more values from that record. Instead of writing procedural code in Visual Basic 4.0 to handle each event that might happen, the programmer writes one routine for each event and does not worry about the order in which those events may or may not happen. Also, the tedious task of selecting the correct event is out of the user's hands; in other words, nowhere in the program does the programmer have to look to see what the user decides to do. When the user changes a record, Windows automatically triggers that field's change event and the code written for that particular event executes.

The lack of event-driven support is not the only reason COBOL programmers should move to Visual Basic 4.0 when writing Windows applications. The most time-consuming task in COBOL is the least time-consuming task in Visual Basic 4.0: designing and developing the user-interface.

COBOL programmers must master the design and programming of user-interface screens and reports. Listing A.2 contains a partial listing of a COBOL program's screen output design. To produce a full screen of output, a COBOL programmer must type many line-by-line descriptions, called PIC clauses, for the screens. (If the COBOL program produces printed output, the programmer must also write tedious descriptions for the reported output lines as well.) The PIC clauses can be bug-prone. COBOL programmers often have to compile their programs many times, adjusting PIC clauses over and over, until their screens display or accept data in a desired format and layout.

Caution

Despite its length, Listing A.2 describes only two formats for output: titles and data. If fields for user input of values are needed, or if additional kinds of detail lines might appear on the screen, additional sets of PIC clauses are required. It is not unusual for a single COBOL program to contain twenty pages of PIC clause listings. A Visual Basic 4.0 program requires no such text listings no matter how many extensive Visual Basic 4.0 user screens are required.

Listing A.2. An example of tedious COBOL PIC clauses.

*  The following code describes part of a COBOL screen.

*  This code would appear before a COBOL program's

*  procedure division but after the identification and

*  environment divisions. The purpose of this code is

*  to show how a COBOL programmer must tediously describe

*  every line of a user's screen.

 WORKING-STORAGE DIVISION.

 01 Detail-Line-Descsripts-1.

    03 PCodeTop             PIC X(7)   VALUE 'Product'.

    03 FILLER               PIC X(30)  VALUE SPACES.

    03 NSoldTop             PIC X(6)   VALUE 'Number'.

    03 FILLER               PIC XXX    VALUE SPACES.

    03 UPriceTop            PIC X(4)   VALUE 'Unit'.

    03 FILLER               PIC XXXX   VALUE SPACES.

    03 EPriceTop            PIC X(8)   VALUE 'Extended'.

*

 01 Detail-Line-Descsripts-2.

    03 PCodeBot             PIC X(5)   VALUE 'Code'.

    03 FILLER               PIC X(5)   VALUE SPACES.

    03 PName                PIC X(12)  VALUE 'Product Name'.

    03 FILLER               PIC X(16)  VALUE SPACES.

    03 NSoldBot             PIC X(4)   VALUE 'Sold'.

    03 FILLER               PIC X(4)   VALUE SPACES.

    03 UPriceBot            PIC X(5)   VALUE 'Price'.

    03 FILLER               PIC X(5)   VALUE SPACES.

    03 EPriceBot            PIC X(5)   VALUE 'Price'.

*

 01 Detail-Line-Data.

    03 FILLER               PIC XX     VALUE SPACES.

    03 ProdCode             PIC X(4).

    03 FILLER               PIC X(5)   VALUE SPACES.

    03 ProdName             PIC X(25).

    03 FILLER               PIC XXX    VALUE SPACES.

    03 NumSold              PIC 999.

    03 FILLER               PIC X(3)   VALUE SPACES.

    03 PriceEach            PIC S9999V99.

    03 FILLER               PIC XX     VALUE SPACES.

    03 ExtPrice             PIC S99999V99.

Visual Basic 4.0 programmers do not use code to describe their screens. Instead, as you've seen throughout this book, Visual Basic 4.0 programmers literally create their applications by pointing and clicking with the mouse. If a text box control does not appear in the correct place the programmer only has to drag the control to the correct location. If a listbox is not large enough to display enough items at one time, the programmer can increase the size of the listbox by dragging the listbox control's edge with the mouse.

Note

You can print a textual description of your Visual Basic 4.0 form (File | Print) and that description does not look much different from a listing of COBOL PIC clauses. The difference lies in the timing of the listing. To produce a full-screen of output in COBOL you must first write the tedious text that describes the PIC clauses that produce the output. In Visual Basic 4.0 you first use the mouse and toolbox to design your form. Visual Basic 4.0 then produces the printed description of that screen that you can use as system documentation. It is much easier and faster, and less error-prone, to design a screen using the mouse than to design the screen using text descriptions.

COBOL's procedure division contains COBOL code that processes the data in the same way that Visual Basic 4.0 procedures process data. Much of COBOL's procedure code is taken up with the displaying and inputting of user data, a task not needed inside Visual Basic 4.0 programs due to the Window's event-handling and the graphical controls already described. The remaining commands in the two languages are actually rather similar in many ways.

Both COBOL and Visual Basic 4.0 contain selection statements that execute certain routines based on data values. Visual Basic 4.0's If-ElseIf statement is virtually identical to COBOL's IF-THEN-ELSE statement. COBOL contains OPEN and CLOSE file I/O commands that mirror those in Visual Basic 4.0.

Once a COBOL programmer accepts the event-driven environment found in Visual Basic 4.0, and once a COBOL programmer understands that a WORKING-STORAGE SECTION describes variables, whereas Visual Basic 4.0 programs require variable-definition statements such as DIM, and once a COBOL programmer learns how to place and adjust controls using the toolbox, the COBOL programmer will find a one-to-one correspondence in almost every COBOL statement to an equivalent Visual Basic 4.0 statement.

Both COBOL and Visual Basic 4.0 certainly have their own particular language idioms and individual statements but the COBOL programmer will not have much trouble understanding the procedural control language of Visual Basic 4.0. The PERFORM statement executes COBOL subroutines just as Call and even Gosub execute Visual Basic 4.0 routines. The breakdown of large COBOL programs into sections and paragraph prepares the would-be Visual Basic 4.0 programmer well for the smaller event procedures found in Visual Basic 4.0.

The primary caveat for newly converted COBOL programmers to the Visual Basic 4.0 environment primarily lies in the separation of data once the COBOL programmer masters the screen-generating window controls. Although COBOL programmers are perhaps the best structured programmers in existence, they are used to a programming environment where every data value is global to the program and available at all times. The secret behind a powerful Visual Basic 4.0 program's success lies in the hiding of data in local variables. In Visual Basic 4.0, a variable available in one routine may be local to that routine and not visible for a different routine. The definition of all data inside a COBOL program's data division makes that data visible to all routines in the subsequent code. Once the COBOL programmer masters the Visual Basic 4.0 programming environment and toolbox controls, that programmer should concentrate on learning how local and global data works inside a Visual Basic 4.0 program. The rest of the language will then pose no major conversion complications.

Table A.2 presents an overview of some of the specific feature comparisons between Visual Basic 4.0 and COBOL.

Table A.2. Visual Basic 4.0 compared to COBOL's significant features.

Visual Basic 4.0

COBOL

C and Visual Basic 4.0

C differs from Visual Basic 4.0 like night differs from day. C is a small programming language. Where ANSI C has fewer than 35 keywords, Visual Basic 4.0 has over 200. The C programmer must rely heavily on special symbolic character operators that perform much of the work in the language. Where Visual Basic 4.0 uses a keyword command to compare two values, the C language uses a special operator in certain instances.

Unlike COBOL, C is primarily a PC-based language. Although C is available on most mainframe and minicomputers today, C's small size made C the ideal language for PCs during the 1980s when ample PC memory and disk space were scarce. The use of C in writing PC-based programs grew tremendously in the decade of the 1980s. Now that the memory and disk storage capacity of PCs rival those of the computer giants in the early 1980s, C's inertia (and its successor, C++, discussed in this appendix's final section) makes C a major player in PC languages today. Almost every data processing shop writing PC-based code, whether for Windows or still for the MS-DOS environment, must make the C-or-Visual Basic 4.0 decision. Both languages offer advantages and disadvantages that complement each other.

Despite its small language, C is difficult to learn when compared to Visual Basic 4.0. C is cryptic and Visual Basic 4.0 is verbose. Even well-written C code can be confusing to an expert, whereas well-written Visual Basic 4.0 code can be somewhat self-documenting. Despite its small vocabulary, C requires time to master, but a programmer can begin writing Visual Basic 4.0 programs quickly.

The size and learning curve of the two languages are not the only considerations one must make when deciding between C and Visual Basic 4.0. C programs are compiled whereas Visual Basic 4.0 programs are interpreted. Although the compile versus interpret arguments were presented earlier in this appendix's first section discussing BASIC, the development discussion is more critical when discussing C over the earlier BASIC languages. C is an extremely efficient language. C's speed virtually rivals assembly language speed when written with efficiency in mind. In time-critical applications, such as embedded code found in automated test systems and flight simulators, C's speed is critical to the success of the application. There is no way to consider Visual Basic 4.0 in such an application despite today's fast computers.

Given the huge speed advantage that C offers over Visual Basic 4.0, speed is rarely important these days to most final Windows applications. Nobody wants sluggish applications, and a Windows application is often many times slower than an equivalent MS-DOS application. Nevertheless, Visual Basic 4.0 was never intended to be used in time-critical applications. It was intended to be used to produce powerful Windows applications very quickly. Visual Basic 4.0 provides the ability to write user screens and prototypes during the program's design and the programmers can then turn those screens and prototypes into final working applications quickly.

The C programming language was originally the primary language used when writing Windows applications. Perhaps the speed of C was the reason for the selection of C as the original de facto standard Windows language. C, however, is a terrible language for designing Windows program prototypes. C is a terrible language for moving from design to finished product quickly in the Windows environment. In addition to a slow development cycle, the learning curve for the C language is only the first step in writing Windows programs using C; the detailed and tedious architecture of a Windows program must be fully understood by C programmers before a single simple Windows program can be written in C.

When writing a Windows program, you've got to consider the design ease and speed of development for that program. A simple C program that does nothing more than display a three-word phrase requires over one hundred C statements and a huge understanding of Windows internal function calls and architecture. The same program requires about ten mouse clicks and one or two lines of code when using Visual Basic 4.0. Developers simply cannot ignore the learning curve advantages and development time improvements that Visual Basic 4.0 provides over C.

When writing Windows programs using C, the C programmer must not only write code to process data and respond to controls, but the C programmer must also control the Windows environment and check for all the conditions expected by and of the user. Visual Basic 4.0 hides most of the standard Windows interaction from the programmer. Although the Visual Basic 4.0 programmer can modify control properties, check for all property values, manage the window's display, and handle mouse movements and keyboard input, the Visual Basic 4.0 programmer does not have to mess with all those tedious details because so much of the Visual Basic 4.0 environment does this work for the programmer. Of course, that buffering of responsibility is one reason why Visual Basic 4.0 runs slower than C programs (in addition to Visual Basic 4.0's interpreted nature).

The advantage that C programmers realize when writing Windows programs is the low-level availability of the system that C accesses. Through function calls and bitwise operators, C lets the programmer program down on the computer's "bare metal." Although Visual Basic 4.0 does provide support for low-level programming, through hex constants, internal function calls, and bitwise-like manipulating keywords such as AND, OR, XOR, EQV, and NOT, the typical Visual Basic 4.0 programmer needs none of these low-level language tools and will be through writing and testing scores of Windows programs before a C programmer can finish debugging a single program.

At programming conferences around the country, the C versus Visual Basic 4.0 discussion often arises. The lecturer often responds to the arguments being presented for and against both languages like this: "Design and prototype your application using Visual Basic 4.0. Once your users sign off on the specs, then take those specifications and write your efficient projects using straight C."

The problem is that, as hinted at earlier in this section, when you design user screens and prototype your programs using Visual Basic 4.0, with fully-working menus, controls, and dialog boxes that are so easy to produce using the Visual Basic 4.0 development environment, you have almost completed the application! Of course, depending on the data processing required behind the scenes, there may still be many hours of programming left to tie those Windows prototype elements together. Nevertheless, you will have those same elements to tie together in C which makes the process more difficult and lower-level. At of the time of this writing, there is no reliable Visual Basic 4.0-to-C screen and prototype converter that transforms Visual Basic 4.0 screens, menus, and controls, into their C equivalents. Even if there were such a conversion method the time required to find the C programming hooks needed to tie the controlling elements together would be too costly to justify the effort in many programming projects.

Early releases of Windows did not include a free Visual Basic run-time distribution package. Early Visual Basic developers had to ensure that the Visual Basic runtime system, such as VBRUN200.DLL was placed in the user's Windows directory before the user ran Visual Basic programs. Windows 95 contains the runtime DLL file needed to run Visual Basic 4.0 applications. Visual Basic 4.0 developers no longer have to fear the user being without the needed runtime code. Although Visual Basic 4.0 programs are not truly compiled programs, they are as tamper-proof as compiled programs are when converted to .EXE files through Visual Basic 4.0's Run menu. The speed of today's machines makes lack of speed an unimportant Visual Basic 4.0 issue. Yesterday's advantages to the C language simply cannot be justified today in most situations where the C versus Visual Basic 4.0 question arises.

Note

C is not the same language as C++. There are some valid arguments to be made for developing Windows applications in some versions of C++ as described in the final section of this appendix.

Table A.3 presents an overview of some of the specific feature comparisons between Visual Basic 4.0 and C.

Table A.3. Visual Basic 4.0 compared to C's significant features.

Visual Basic 4.0

C

Pascal A Language Whose Potential Has Gone

Pascal offers most of the advantages of C although C produces slightly faster runtime code than Pascal. Pascal is a fairly small language. It is often a system-dependent language although today's de facto standard PC version of Pascal, Borland Pascal, discussed in a moment, runs extremely well on PCs under the Windows environment.

Pascal was designed in the 1970s to be a major player in the small-computer market. It was thought by some that Pascal would take over most other programming languages due to its structured approach, data flexibility, ease of use (once mastered) over more rigid programming languages of the day such as COBOL and FORTRAN, and its small size. In short, Pascal was going to be what C actually became in reality: The language that was going to be used by virtually every programmer.

During the 1970s and into the 1980s, Pascal did succeed in turning many programming communities into Pascal-only shops. Developers used Pascal in early PC software when assembly language development could not be justified. Sad for many people, however, Pascal surprised the language stalwarts by virtually dying out to make room for C. In the span of a year or two during the mid-1980s, C streaked past Pascal as the language of choice and Pascal almost died completely.

Almost. Borland International, never let Pascal die completely. Almost single-handedly, Borland's Turbo Pascal kept Pascal inside many programming circles, despite the fact that the programming community favored C (and still does by a large factor). About the time that Microsoft released the first version of Visual Basic, Borland released an object-oriented Pascal called Turbo Pascal With Objects and new life surged into the Pascal language.

Note

Today C++ is such a more popular and widely-used object-oriented programming (OOP) language than Pascal with objects, that a more formal discussion of OOP is left for the next section that discusses C++.

As Microsoft added features and support to Visual Basic, Borland continued to hone Turbo Pascal (along with their Turbo C and Turbo C++ languages). Today, it is rare to find a Windows programming magazine or journal that does not contain at least one article or reference to a Windows program written in Turbo Pascal. Pascal, however, suffers the same fate that C suffers when developing Windows programs: Despite its respect as a well-written, structured, efficient, small programming language, it is precisely that detailed advantage that makes Pascal almost too sharp of a tool to use in favor of Visual Basic 4.0. Development time is simply too costly in most programming shops and the backlog of programming projects is too huge to ignore for developers to realize benefits using Pascal (or its object-oriented cousin) in Windows development.

Note

Programmers will find that the conversion of procedural sections of code between Visual Basic 4.0 and Pascal is simple. Both languages support similar data definitions, controlling commands, looping statements, and string support. The only major language difference that will appear is your compiler's support for Windows programs. Turbo Pascal, for example, performs Windows interactions much differently from Visual Basic 4.0.

There are some Pascal die-hards who, using the tools available in such languages as Turbo Pascal with Objects, truly can develop Windows applications more quickly than C programmers. The compiled speed advantages of Pascal over Visual Basic 4.0 also cannot be ignored in some specific time-critical applications. Nevertheless, all the Visual Basic 4.0 advantages over C still apply to Pascal. Pascal is a high-level language that often acts like a low-level one. Development in Pascal can be time-consuming. The visual nature of today's Pascal languages, such as the new versions of Turbo Pascal, still do not hold a candle to development speed possible under Visual Basic 4.0.

The sheer number of C and C++ programmers over Pascal programmers help ensure that Pascal will remain in the secondary programming community and stay out of most mainstream data processing organizations. Pascal is an excellent tool for learning to program correctly and many universities rightly require students to pass Pascal before venturing into "real" languages of C and C++. Although there will probably always be those who make Pascal their development language of choice, those number of people are dwindling as the number of Visual Basic 4.0 programmers increase.

Table A.4 presents an overview of some of the specific feature comparisons between Visual Basic 4.0 and Pascal.

Table A.4. Visual Basic 4.0 compared to Pascal's significant features.

Visual Basic 4.0

Pascal

C++ The True Visual Basic 4.0 Opponent

The C++ language contains all the advantages and disadvantages of C—and then some. C++ is efficient. Despite more advanced compiler required for the language, today's C++ programs are almost exactly as efficient as similar C programs. A C programmer can learn the fundamental differences between C and C++ in a matter of a few minutes of study. The complete discussion in this appendix's section on the C language applies to C++. The differences begin to appear when one adds object-oriented programming to the C and C++ mixture. C++ is an improved C language, with additional support for object-oriented technology.

OOP is much more important to C++ than it is to Pascal. Although the OOP hooks that Borland gave to Turbo Pascal with Objects breathed new life into Pascal and kept the language active longer than it may have stayed active otherwise, the OOP in C++ took over the programming world in a frenzy. Today, programmers are scrambling to add C++/OOP notches to their programming tool belts.

There are two heavy-hitting C++ Windows development tools on the market today and they are Microsoft's Visual C++ and Borland's Borland C++. There are several other C++ Windows development languages offered by other vendors but Microsoft and Borland get the most sales numbers with tools used by programmers who can produce reliable, quick, efficient, and effective Windows programs.

Before learning why Visual C++ and Borland C++ are the major contenders to Visual Basic 4.0, you should get an idea of the nature of object-oriented languages. Although complete books have been written to explain OOP, here are some of the fundamentals that separate an OOP language from a non-OOP language:

• In theory (although not always in practice), programs written using OOP technology should be faster to write and easier to modify.
  
  
• Through OOP technology known as data abstraction, your data values act more like their real-world counterparts. Instead of creating a data structure containing the same information as a customer record as you would do in Visual Basic 4.0, for example, an OOP customer representation (an example of an object) would act in the program just like a customer that can be added to the company's books, changed, deleted, or printed on a report. The code that describes, initializes, and uses that customer will use commands that behave like real-world interactions you would perform with customers; your programs will contain such commands as GetCustomer and ChangeCustomerData. The end result is be an OOP program that often reads like a physical representation of the data bringing the programmer closer to the data and removing layers of buffering between data and the real-world physical counterparts that the data represents.
  
  
• A part of OOP technology called inheritance makes extending capabilities of existing OOP program sections and data values easier. Therefore, you are able to reuse pieces of programs in other programs, building new programs as you might build a modular home.
  
  
• OOP programs are safer due to an OOP technology called encapsulation. Through encapsulation, only portions of a program or routine that needs access to a data value gets access to that value. The concept of local and global data values goes far beyond the usual terminology when you add the encapsulation ability.
  
  

OOP is not necessarily a major language change. Instead, it is more of an approach to data and programs that should, whenever fully implemented, make programmers more productive. There is one major drawback to C++ and the OOP combination, however, and that is the learning curve needed to master C++ and OOP.

Add to the learning curve of C the equal, and often more time consuming, learning curve needed to master OOP skills. While the beginning programmer moves at a snail-like pace through his or her introductory programming language to C, to C++, and finally to OOP-based C++, other programmers using Visual Basic 4.0 will have produced so much productive, working, and debugged code that the C++/OOP programmer will wonder where to sign up for Visual Basic 4.0 classes!

Due to the learning curve and the added burden of interfacing to a Windows programming environment by using a C-like language, C++ would not be a major contender in the world of Windows programming if it were not for a new use for OOP that Microsoft and Borland quickly introduced into their C++ Windows programming products: application frameworks. An application framework is a tool, implemented using OOP technology, that lets you quickly develop a Windows program shell, complete with menus and controls, to which you then can add underlying C++ code that links the controls together and also add your own data processing specifications to the application. The end result will turn a shell of a Windows application (the prototype) into a complete working application.

Borland's application framework is called ObjectWindows Library and Microsoft's application framework is called the Microsoft Foundation Classes. Although the market does not always determine the best tools for a given job, especially in the field of computers, Microsoft seems to be leading the sales and the majority of Windows development using C++ seems to be done today using the Microsoft's Visual C++ development system.

Where does Visual Basic 4.0 fit into this C++ language discussion? These C++ application framework tools help bridge the gap between the novice programmer and advanced Windows applications. You'll remember from an earlier section that C programmers cannot quickly produce running prototype Windows applications and initial working code due to the complexity of writing Windows programs in C. Therefore, many developers forego using C for Windows development these days due to the power of Visual Basic 4.0.

Caution

Despite the similar names, Visual Basic 4.0 and Visual C++ have very little in common. The interfaces, languages, and ease of application development, are extremely different between the two languages.

The application framework seems to level the programming playing field somewhat. Using the application frameworks, a C++ programmer can develop working prototypes of Windows programs virtually as quickly as the Visual Basic 4.0 developer. Therefore, users can more quickly accept or reject program designs (one of the typical bottlenecks in most program development projects) and projects can more quickly be completed. Once the menus, controls, and user interfaces are in place, the programmer uses the C++ underlying language to connect the controls and to add the application-specific calculations and procedural requirements.

Major software developers are using these C++ application frameworks, especially Visual C++, to develop their programs for distribution. The development time is cut down from the typical C-based Windows development environment because

1. The programmers quickly develop prototypes (application shells) using the application framework.
   
   
2. The OOP advantages of C++ over C and most other procedural languages make extending that application framework and shell easier than could be done without the tools of OOP. Instead of low-level C code being used to add the meat behind the applications, the extensible object-oriented code makes adding the final glue to the framework easier than possible without OOP's tools.
   
   

However, there is one problem that still lurks in the C++/OOP application framework development system that you should understand before throwing out Visual Basic 4.0 for a new copy of Visual C++ or Borland C++: Although the application framework makes initial application development (the application's design and shell) simple, you must understand the in-depth relations of object orientation before you can do anything more with the application's shell. You must master the mechanics of C++'s inheritance, abstraction, and encapsulation features before you are able to add one line of code to the application's shell created by the framework. Therefore, despite the tremendous advantages that these application frameworks provide for those already skilled in advanced OOP programming techniques, these frameworks still do little for the introductory programmers and for the non-OOP programmers who want to produce Windows programs quickly.

In addition to mastering OOP technology in depth, the C++/OOP programmer must also be versed in the Windows internal routines supported by these framework development systems. Visual C++ and Borland C++ support hundreds and hundreds of Windows function calls. Although many of these calls have been simplified for the frameworks (unlike the poor C Windows programmer who must master the hundreds of Windows internal function calls with no simplification), the Windows developer using a C++/OOP framework must eventually get acquainted with hundreds of supported Windows routines that size windows, draw graphics, support mouse controls, and perform all the other mundane and critical Windows responses needed in even fairly simple Windows applications.

Visual Basic 4.0 does not require the steep learning curve that these major development tools require. It is true that with major development systems, such as Borland C++ and Visual C++, programming communities can be extremely productive and write extremely advanced and major Windows applications that run efficiently and as true compiled applications. Visual Basic 4.0's interpreted nature simply does not support major developments such as Microsoft Excel or WordPerfect for Windows. For those programming shops with major programming talents, the C++ application frameworks are the definite tools of choice.

Table A.5 presents an overview of some of the specific feature comparisons between Visual Basic 4.0 and C++ with OOP capabilities.

Table A.5. Visual Basic 4.0 compared to C++'s significant features.

Visual Basic 4.0

C++ with OOP

Summary

You've made it this far through the book so you obviously have a strong interest in using Visual Basic 4.0 to create Windows applications. You are probably already using Visual Basic 4.0 for some application development.

This appendix tried to answer a few questions you may have had concerning the acceptability of Visual Basic 4.0 as a serious Windows development tool as opposed to other languages you can use. If you have some or extensive background in other languages and are fairly new to the Visual Basic 4.0 environment, perhaps this appendix helped you categorize several of the other popular languages still in use and compare those languages with Visual Basic 4.0.